home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
ospf
/
ospf-minutes-92jul.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
8KB
|
176 lines
Editor's Note: Minutes received 7/31
CURRENT_MEETING_REPORT_
Reported by John Moy/Proteon
Minutes of the Open Shortest Path First IGP Working Group (OSPF)
The OSPF Working Group met at the July 1992 IETF in Boston. The Minutes
from that meeting follow.
The meeting began with a review of the four documents that are currently
be considered for publication by the Working Group:
1. The updated OSPF V2 specification. This will supersede RFC 1247.
Unfortunately, the document was not available prior to the meeting.
(A limited number of paper copies of the updated specification were
made available to implementors, and the specification was made
available for anonymous ftp after the meeting.) An excerpt from
the document briefly detailing the changes was handed out, and the
changes (all backward- compatible) were discussed. It was also
decided to make one additional change: it will now be possible to
specify a set of area address ranges that will not be advertised in
summary-LSAs. This will enable a network administrator to hide
certain networks within their local areas. This change has already
been implemented by some vendors.
2. The updated OSPF V2 MIB. This will supersede RFC1253. Fred Baker
outlined the proposed changes. It was also decided to make
additions for the multicast routing extensions and the new NSSA
area option. An addition to the Area Range Group was also made for
the above ``hidden network'' feature. An additional request for a
network mask in the new external-LSA table entries was not acted
upon.
3. The OSPF Trap MIB. Rob Coltun led the discussion. There was some
question whether an additional error code should be added for
receiving Illegal-LSAs. It was decided that this would probably
already show up as retransmissions by the faulty sender, and as
such was unnecessary. It was also decided to have the
ospfLsdbApproachingOverflow trap occur at a configurable database
size, instead of 90 percent of the maximum (as stated in the
draft).
4. The OSPF NSSA option. Rob Coltun spent some time explaining how
they work, spending time on the translation between type-7 and
type-5 LSAs, and how you could distinguish a ``local'' type-7
default from one that can be translated into a global type-5
default. No changes were made to this document.
Osmund deSouza presented a proposal for running OSPF over Frame relay.
There was general agreement on the problem: Frame relay is in general
not full-mesh connected, and the network administrator sometimes wants
to assign different costs to different PVCs. For these reasons, OSPF's
1
non-broadcast model is not directly applicable. There was also general
agreement on the solution: instead of treating the connection to Frame
relay as a single OSPF interface, define an OSPF interface as some
collection of PVCs. There was a long discussion of how to represent
this in terms of MIB II and the OSPF MIB. It was decided that Osmund et.
al., with the help of Fred Baker, would rewrite their present document
more along the lines of a usage document. With this document in hand,
it would be hoped that equipment from different vendors would be able to
interoperate using OSPF over Frame relay.
John Moy presented an alternative model for running OSPF over Frame
relay, where there would be a single interface to the frame relay net
and a) neighbors would be discovered dynamically using Inverse ARP b)
OSPF Hellos would be used to build a spanning tree among Frame relay
connected routers, for purpose of update distribution (database
synchronization) c) by default, only these spanning tree links
(adjacencies) would be included in router-LSAs and d) to get better
routing across the Frame relay, more PVCs could be included in the
router-LSAs or (not as good) a variant of short-cut routing could be
used. John's main reason for preferring this approach is that it didn't
need a human to configure it, and that it was optimal in terms of
routing traffic. This proposal was not generally well received, being
characterized as either too complicated or too different than current
practice. John said that he would write it up anyway if he had the
time.
John Moy presented a proposal for dealing with OSPF Database Overflow.
In this proposal, only the number of type-5 LSAs would be limited. The
reasoning being that these constitute a majority of the database in
places like the NSF regionals. A limit for the number of these LSAs
would be set identically in each of these routers, either via SNMP or
negotiated in a new LSA type or in OSPF Hellos. Then, when the limit is
reached in a router it a) won't accept any more and b) will flush all
its self-originated type-5 LSAs, refusing to originate any more. The
claim is that this logic produces an identical database in all routers,
with less than the configured maximum number of type 5 LSAs, no
continual retransmissions, and all internal routing intact.
Enhancements to this scheme could involve limiting other LSA types
(e.g., summaries), and to begin again to originate type-5 LSAs after a
random time lag to automatically deal with temporary overflow.
John said that a similar scheme has been used in Proteon routers for
several years. The proposal was characterized by some Working Group
members as being like congestion control, and some desire for an
additional congestion-avoidance-like mechanism was expressed. Some
people also requested a way to prioritize the order in which excess
advertisements are flushed (e.g., you might want to flush the default
routes last). John promised to sort through the enhancements and
publish a coherent Internet Draft.
Rob Coltun ended the meeting with a quick discussion on how hierarchical
routing information might be injected into OSPF, in order to support any
of the schemes for IPV7.
2
Attendees
J. Allard jallard@microsoft.com
William Babson bill@penril.com
Dennis Baker dbaker@wellfleet.com
Fred Baker fbaker@acc.com
John Ballard jballard@microsoft.com
Ken Benstead kbenstead@coral.com
Geetha Brown geetha@decvax.dec.com
Steve Buchko stevebu@newbridge.com
Greg Celmainis gregc@newbridge.com
Frank Chen frankc@casc.com
Dean Cheng dean@sun2.retix.com
Robert Ching natadm!rching@uunet.uu.net
Chris Chiotasso chris@artel.com
Henry Clark henryc@oar.net
Rob Coltun rcoltun@ni.umd.edu
Jim Comen comenj@interlan.interlan.com
Michael Davison davison@cs.utk.edu
Osmund de Souza osmund.desouza@att.com
Dino Farinacci dino@cisco.com
AnneMarie Freitas afreitas@microcom.com
Vince Fuller vaf@stanford.edu
Kelly Furlong kelly@kyle.ksc.nasa.gov
Der-Hwa Gan dhg@nsd.3com.com
Ian Heavens ian@spider.co.uk
Jeffrey Honig jch@nr-tech.cit.cornell.edu
Steven Hubert hubert@cac.washington.edu
Ronald Jacoby rj@sgi.com
Dwight Jamieson djamies@bnr.ca
Dan Jordt danj@nwnet.net
John Krawczyk jkrawczy@wellfleet.com
Alan Kullberg akullber@bbn.com
Whay Lee whay@merlin.dev.cdx.mot.com
Anthony Lisotta lisotta@nas.nasa.gov
Robin Littlefield rlittlef@wellfleet.com
John Moy jmoy@proteon.com
Erik Nordmark nordmark@eng.sun.com
Benny Rodrig 4373580@mcimail.com
Manoel Rodrigues manoel_rodrigues@att.com
Henry Sanders henrysa@microsoft.com
Hellen Sears sears@interlan.interlan.com
Martha Steenstrup msteenst@bbn.com
Linda Tom toml@interlan.interlan.com
Kannan Varadhan kannan@oar.net
Scott Wasson sgwasson@eng.xyplex.com
Luanne Waul luanne@wwtc.timeplex.com
Honda Wu natadm!honda@uunet.uu.net
3